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The database organizations within three different NASA projects have advanced current 
practices by creating database synergy between the various spacecraft life cycle stakeholders 
and educating users in the benefits of the Consultative Committee for Space Data Systems 
(CCSDS) XML Telemetry and Command Exchange (XTCE) format. 


I. Introduction 

T he James Webb Space Telescope (JWST) is a large aperture infrared space telescope with a five-year 
mission and ten-year design goal. It is currently scheduled to launch in 2013 from Kourou, French Guiana 
aboard an Ariane 5 launch vehicle. JWST is 
designated to succeed the Hubble Space Telescope 
(HST) as part of the National Aeronautics and Space 
Administration (NASA) Great Observatories 
program. JWST will continue the HST tradition of 
advancing breakthroughs in our understanding of the 
origins of the earliest stars, galaxies, and the 
elements that are the foundations of life. 

The importance of operations in the mission life- 
cycle is sometimes overlooked during the 
development phase. Due to the long duration of 
JWST from over 20 years of development until end- 
of-life the project has made a conscious decision to 
involve operations personnel from the beginning. 

JWST system engineers gathered in 2000 to look at 
various options, technologies, and industry trends to 
determine how to implement this objective. The 
JWST operations team performed studies to 
implement best practices and lessons learned from 
other GSFC long-term missions, such as HST and Earth Observation System (EOS). The major key decisions for 
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operations were; use of Consultative Committee for Space Data Systems (CCSDS) standards and institutional 
capabilities, use of the same command and telemetry system for I&T and operations, and decouple the project 
reference database from the command and telemetry system. The JWST ground system is based on EOS and HST 
heritage and the lessons learned from these large scale missions. For HST, as systems were upgraded data 
conversion to a newer format became a major issue. For EOS, the early real-time ground system was not ready to 
support operations and was replaced by COTS system that was to be used for real-time operations. JWST is using 
the Raytheon Eclipse system for operations as well as for its software and hardware development and I&T activities. 
Some of the major JWST enhancements to EOS version of Eclipse include providing a fast turn around (minutes) of 
database updates and storing the engineering data in a generic decommuntated format. A departure from both HST 
and EOS is that JWST is consolidating the science and mission operations. 


The Landsat Data Continuity Mission (LDCM), shown in figure 2, is scheduled to launch in July 2011 and will 
capture space-based land remote sensing images consistent with predecessor 
Landsat satellites. The LDCM will provide repetitive acquisition of high 
resolution multi-spectral data of the Earth's surface on a global basis. The 
data from the Landsat series of satellites constitute the longest record of the 
Earth's continental surfaces as seen from space and are a valuable resource in 
the study of agriculture, education, business, science, and government. In 
order to reduce the effort to coordinate modifications to ground system 
databases seen in previous NASA missions, the LDCM project made a 
decision during the development of ground system requirements to maintain 
an integrated project reference database of all configuration managed data 
necessary to develop, test, and operate the Mission Operation Center (MOC). 

Like JWST, LDCM is consolidating it’s science and mission operations in the 
United Stated Geological Survey (USGS) Sioux Falls, South Dakota facility. 

The LDCM Project will have a common database for I&T and the operational 
system. LDCM, however, started from an initial baseline using the JWST 

XML database and CCSDS XML Telemetric and Command Exchange (XTCE) to develop its own database 
structures and tools. 



Figure 2. LandSat. 


NASA has formed the Constellation Program, Orion spacecraft shown in figure 3, to maintain American 
presence in low Earth orbit, returning to the moon for purposes of establishing an outpost, and laying the foundation 
to explore Mars and beyond. The Constellation Program’s heritage rests on 
the successes and lessons learned from NASA’s previous human spaceflight 
programs: Mercury, Gemini, Apollo, Space Shuttle and International Space 
Station (ISS). Constellation define its operation architecture in Command, 

Control, Communications and Information (C3I) specification. Realizing the 
Constellation needs to support multiple locations, such as Marshall Space 
Flight Center (MSFC), Johnson Space Center (JSC), and Kennedy Space 
Center (KSC), and multiple users services like the lunar surface, lunar orbiting 
satellites, International Space Station and earth, the C3I defines the operability 
specification for connecting this different diverse systems. Constellation C3I 
maximizes the uses of standards and it will be the first major NASA netcentric 
I- based system. Constellation will have a distributed science and mission 
operations, where KSC, JSC, and MSFC each have their own command and 
telemetry systems, analysis tools, and databases. This diversity in the Constellation Program means a consistent 
mechanism for moving the databases and products between different vendors, suppliers and international partners as 
needed. Since Constellation Program will mature for several decades the flexibility of XML and the definition of 
CCSDS XTCE will help achieve the goal of providing databases to dissimilar systems. 



The focus of this paper is the need for all three of these long term programs to have databases to last a decade or 
longer for I&T activities, mission support, and data processing. Also these three programs have international 
partners and a diverse user community for supplying equipment. CCSDS XTCE uses XML format and can provide 
a means of sharing the core database information in a consistent non-proprietary format. 
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II. The Advantages of Stand Alone Database using XML 


Control centers that support multi-missions and long 
term modem missions both at the European Space 
Agency (ESA) and NASA, recognize that moving and 
maintaining databases between dissimilar systems is risky 
and costly. While some Commercial-Off-the-Shelf 
(COTS) products may reduce a mission’s development 
and software support costs, for missions of long duration 
that benefit might be reduced due to non-backward 
compatible software updates or elimination of feature 
support. To eliminate vendor dependency and reduce 
licensing cost JWST decided to use Open source XML 
rather than traditional data base programs. 

XML allows for the data to be stored in a manner that 
allows it to be easily transformed, ingested, and accessible 
to many other systems. A sample of the database XML is 
shown in figure 4. The following paragraphs will describe 
each program’s experience. 

A. JWST Program 

In 2001, the JWST database team started prototyping 
the JWST XML using the Earth Observation System 
(EOS) satellite database. This database contains about 
25,000 data items for command and telemetry, which is 
the expected size of the JWST database. Once the 
database was converted from a COTS format to the XML, 
it took one person two weeks to complete the first steps in 
evaluating XML for performance, sizing, and exchanging 
the data between systems. The data is presented in the 
COTS in a typical user friendly web view. This web 
view, as shown in figure 5, hides the complexity of the 
XML data and with style sheets provides the first level of 
checking performed on the data. It is important to begin 
checking the data as the user enters it, so problems are 
found early and in a location that is easily corrected by 
the user. XML is the data at the bottom of the structure 
that is interpreted by the applications that presents the 
data to the user, see figure 6. 

The performance testing showed that database 
conversions to multiple formats could be accomplished in 
minutes using a standard desktop PC running Windows. 
For the JWST database each command and telemetry 
mnemonic would be a separate container or file. For 
example, if there are 200 commands in the database, then 
200 containers would be delivered in a command folder. 
The sizing testing indicated no issues with each command 
and telemetry file about 4KB in size, for a total of 
100MB. The user interfaces were developed using a few 
key goals. The first goal is to use standard web browser 
interfaces so any workstation can use the database 
interface without having special software. The second 
goal is to remove any of the XML tags and code from the 
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Figure 4. XML Sample. 



Figure 5. User Display. 
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user experience. The third and final goal, the input form is to check for legal values to identify as many errors as far 
forward in the process as possible to reduce the amount of re-work the user would need to do. 


USER LAYER 


APPLICATION LAYER 


The JWST database is currently one of the largest XML spacecraft databases for the real-time and offline 
systems at Goddard Space 
Flight Center. The current 
database system is 
available to 34 distinct 
laboratories, each 

geographically dispersed, 
having local database tools 
to work with the XML 
databases. Each of these 
laboratories database tools 
are used for the exporting 
and importing of data both 
locally and to the central 
database system, inputting 
data to the database 
certification process, and 
providing various reports. 


EXCHANGE LAYER 



Figure 6. XML Layers. 


B. LDCM Program 

The decision by LDCM management to maintain a centralized project reference database was made early in 2007, 
prior to the selection of instrument, spacecraft, and ground system vendors (as of this writing, only the instrument 
vendor has been selected). As part of this decision, the project evaluated the JWST design and concluded that its 
XML data exchange format was appropriate for LDCM. The decision was based on a number of factors, including 
the application independent, ASCII-based structure of XML, the compatibility with the CCSDS XTCE standard, and 
the proven performance of the JWST system. Like JWST, LDCM will gather database contributions from external 
laboratories, albeit on a smaller scale. While many COTS product are currently able to import XML structures, the 
utility of Extensible Stylesheet Language Transformations (XSLT) allows external users who cannot directly ingest 
XML into their applications to convert the database to an acceptable format. The reduction in cost, associated with 
the non-proprietary and flexible transformation characteristics of XML, in addition to the minimization of risk, due 
to the commonality of database field interpretation taken from the XTCE standard, further substantiated the 
appropriateness of XML as the database format. 

C. Constellation Program 

The Constellation Program C3I specification looked for standard ways of defining it’s interfaces. C3I uses 
CCSDS XTCE as a means to describe the database as well as provide an exchange method . The experience of 
many of the Constellation personnel are from the NASA manned flight programs, including the space shuttle and 
International Space Station. The experience of these personnel meant that changes occurred very slowly and 
methodically and with the introduction of CCSDS XTCE very few Constellation personnel with little real world 
experience with XML. At the 2007 CCSDS committee meeting in the Spacecraft Monitor and Control working 
group, the Constellation and XTCE personnel took an existing space shuttle database and provided a comparable 
CCSDS XTCE database in about 10 hours. Based on this effort it was felt that using CCSDS XTCE as both the 
mission command and telemetry database as well as exchange formats was entirely feasible. The Constellation 
Project continues to evolve the databases needed to support the various systems and elements using XML and 
CCSDS XTCE where applicable. With the launch dates for Ares and Orion coming closer, Constellations is 
redefining the portions of it’s C3I information model to focus on command and telemetry using XTCE. 


III. Evolution of CCSDS XTCE Standard 

Declaring XTCE as an open standard exchange format and what this means has been one of the challenges. 
JWST personnel first heard of the emergence of XTCE as a combined OMG/CCSDS standard at a conference in 
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2004. A draft of the proposed XTCE standard was presented and JWST personnel had concerns that the current 
implementation of the JWST database would not confirm with the proposed standard and would violate a JWST 
project requirement to be compatible with the CCSDS standard. Due to the JWST commitment to conform with 
standards, JWST personnel started meeting with various industry standard groups, such as the OMG and the CCSDS 
Spacecraft Monitor and Control Working Group, to ensure that JWST XML maintained a level of compatibility with 
the draft standard and assisted in writing of the CCSDS XML standard. Working with the standards was especially 
challenging for a pure CCSDS project like JWST, as the standard was trying to address both TDM and CCSDS 
users, that complicated the standard with what JWST considered ‘extra’ tags. 

In helping to develop the standard, the JWST Project took the role of coordinating with the developers of 
Integrated Test and Operations System (ITOS), Advanced Spacecraft Integration and System Test (ASIST) 
command and telemetry systems, and the JPL Mars mission teams to provide a level of consistency among the 
various NASA projects and to build consensus for 
the CCSDS standard. One of the common 
complaints about the proposed standard was its 
complexity and this issue was taken into account by 
the CCSDS standards group. JWST and JPL 
personnel met several times and after reviewing all 
the XML tags and structures, it was discovered that 
the JWST XML database is a subset of the JPL 
XML database. The two different XML databases, 
designed independently from one another, were 
found to be about 95% compatible with other on 
commands and 90% compatible on telemetry 
without any changes to either database. When 
some minor additions were made to the JPL XML, 
the compatibility increased to 100% for commands 
and 95% for telemetry. 

JWST personnel took the inputs from the 
various NASA groups mentioned above and began 
working with OMG and CCSDS members to 
address the complexity of the CCSDS XML standard. The two main contributors to developing the XTCE standard 
working group were ESA/ESOC and NASA/JWST. To help deal with the complexity of XTCE the CCSDS XTCE 
working group developed the ‘green book’ as a user’s guide for the various managers and users not familiar with 
XML to understand the purpose and structure of the CCSDS XML database standard, as shown in figure 7. The 
‘magenta book’ was developed to assist the XML database developers by providing examples, alternative ways of 
using the CCSDS XML tags, and a means to incorporate database items that are not covered under the CCSDS 
standard, as shown in figure 8. 

From the perspective of the JWST Project, the 
experience of working with the CCSDS standards 
group was informative in learning the way 
standards are developed, provided a greater 
appreciation for the amount of time and effort it 
takes to get agreements on a standard, and also 
provided stimulating interaction with dedicated and 
intelligent personnel from the various international 
groups. 




Figure 7. CCSDS Green Book 
XTCE Exchange Concept. 


Figure 8. CCSDS Magenta Book Sample. 
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IV. Beyond XTCE : Tools and Processes 

The success of JWST database is, that in addition to XML and XTCE, it provides tools and processes. These 
tools have been refined during 4 years of experience in the I&T environment. 

• The command and telemetry CCSDS XTCE database standard is only one piece of the entire satellite 
project puzzle. JWST uses XML for display pages, science processing, loads and dumps, engineering data 
requests, and several other products needed for the entire JWST mission. 

• Add XML tags for Configuration management and internal documentation. This will allow for creating 
software generated reports and auditing. 

• Include the database process early at the developer site provides a great benefit in identifying the problems 
early. Prepare an Interface Control Document (ICD) early in the process that describes the data needed, 
allowed values, and any parent/child relationships. 

• For some missions are requiring the developers to deliver the database with the product in CCSDS XTCE 
format, others convert to XTCE after receiving the data, and finally some missions provide tools to the 
developer to assure the database is the same at I&T as well as the mission. No one way is better than the 
other, but chose one process then developed the rules, interface control document, and tools necessary 
before releasing to the users. 

• Do not change tag name. The changing of tag names will have a ripple effect on any software that is used 
to translate the XML into the systems native format. It is often hard to know all the places where the tag 
names are used. The more appropriate means is to add new tags and to retire tags no longer needed. 

• Do not change directory names. As stated above changing the directory name will have the same impact as 
changing the tag names. However, adding and retiring directory names creates issues as well. If needing to 
change do so very infrequently. In general most users of the systems that ingest the database never see the 
lower level database directory structure, so changing the directory name has little value for the end user. 

• Decide early one or many data structure. This data structure will determine the various tools and 
relationships that will be needed to support the database. 

• Provide a database tool kit to the developers. This tool kit provides the view of the database to the end user 
and other tools for checking of the data, submitting of the data and downloading golden databases from a 
central site. The JWST tool kit flow that is used at the developer sites and I&T facilities is shown in figure 
9. 
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Figure 9. Integration and testing Database Tool. 

• Provide conversion tools when adding tags, directories, or required values. The conversion tool, as a stand 
alone piece of software, can convert all the data quickly. A report should be produced that shows what 
items have been added or changed so the user can review. If possible the conversion tool should also 
modify the other database products such as scripts and pages. 

• Include the schema checks in the user toolkit to catch problems early. The style sheets and schemas allow 
for pick lists, range checks, naming rules, and other helpful information so that user input conforms to the 
ICD definitions. This will save rework by the end user and reduce the frustration that often occurs. 

• Include the schemas in the database itself, this will allow for the checks to be updated without effecting 
previous databases where the checks were not enforced. 

• Support Multiple database types; test database for future releases, golden database for current users, and an 
area for incomplete data. 

• Verification reports that check all the content to the database ICD at the user site and the central database 
group. These verification reports often call on other software to do more complex checking that can not be 
easily done with schemas. The verification reports can be used to correct errors prior to submitting the data 
to the central database group. 

• Allow for the database ICD and tags to mature. Since the database is needed early in I&T and as the 
project moves through the various development phases, the data will mature. This maturing data will 
require changes so database groups should plan on it. 

• Allow the users to quickly make new database and merge new database with an existing database. In I&T 
it is not uncommon to have 10 or more databases a day. Also to prevent the natural habit of changing the 
flat files, the database creation should be in the 5 minute or quicker timeframe. 

I&T database tool needs are far more demanding then normal operations, but the investment in the tools and 
creating the data in the proper format is well worth it in the end. 


V. Lessons of XML and CCSDS XTCE 

XML provides many benefits such as long-term support, non-proprietary format and is easily convertible to 
existing applications. These database efforts for the three programs are still ongoing, but the following has been 
noted: 


7 

American Institute of Aeronautics and Astronautics 

092407 






• Translating a mission XML database to XTCE is not difficult. 

• A common mission XML format between dissimilar systems is possible. 

• A common tool set for viewing and organizing the XML and XTCE is useful. 

• Command XML and XTCE is more complex than telemetry. 

• For non-XTCE data, the use of XML metadata to describe item such as pages and scripts was needed due 
to the proprietary nature of most current ground systems. 

Understanding that XTCE was designed as an exchange format and not a mission database is key. Although 
XTCE can be a mission database for the command and telemetry structures, there are many other pieces needed to 
make a complete database. 

XTCE and XML in general are read by computer systems, not people, so only the programmers need to 
understand XTCE/XML tags. The users of the data use a COTS or a web interface that will present the data in a 
user friendly manner. 


VI. Summary 

The combination of XML for managing program data and CCSDS XTCE for exchange is a robust approach that 
will meet all user requirements using Standards and Non proprietary tools. 


COTS tools for XTCE/XML are very wide and 
varied. To combine together various low cost and 
free tools can be more expensive in the long run than 
choosing a more expensive COTS tool that meets all 
the needs. This was especially important when 
deploying in 32 remote sites with no need for 
licenses. 

A common mission XTCE/XML format between 
dissimilar systems is possible and is not difficult. 
Command XML/XTCE is more complex than 
telemetry and the use of XTCE/XML metadata to 
describe pages and scripts is needed due to the 
proprietary nature of most current ground systems. 
Other mission and science products such as spacecraft 
loads, science image catalogs, and mission operation 
procedures can all be described with XML as well to 
increase there flexibility as systems evolve and 
change. Figure 10 is an example of a spacecraft table 
load. 

The word is out and the XTCE community is 
growing, The first XTCE user group was held in 
October and in addition to ESA/ESOC, SC02000, 
and CNES identified several systems based on 
XTCE. The second XTCE user group is scheduled 
for March 10, 2008 with LDMC and others joining. 
As the experience with XTCE grows and the user 
community receives the promised benefits of using 
XTCE and XML the interest is growing fast. 
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Figure 10. Table Example. 
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